Computer programs frequently rely on external software libraries to provide necessary functionality. These software libraries—also referred to as software repositories—are typically collections of software modules that are designed to perform a variety of tasks pertaining to a given subject matter. To employ the capabilities of a given software module residing in a library, a programmer typically writes an application program, usually in the same language in which the library has been coded. The application program normally includes an appropriate procedure call according to the exact syntax necessary to invoke the desired module. Depending on the way the desired module has been coded, certain parameters and other data may also be supplied as part of the procedure call, in order to invoke the module properly and to achieve the desired result. In object-oriented languages, the concept of using previously-developed software modules residing in libraries has been broadened to include the use of software objects. Software objects are self-contained software building blocks that incorporate data as well as processing logic.
When an existing software library is modified in order to correct errors or to provide new functionality, the interface portions of the software modules in the library may be changed. For example, a new parameter may be added, an existing parameter may be deleted, or an optional parameter may become mandatory. Such updates to the interface portions of existing software libraries may jeopardize the proper operation of application programs that were designed to use previous versions of these software modules. Unless a programmer of an application program is notified when a module in a software library has been changed, the application program may no longer function as designed. Instead, unpredictable errors may occur when a changed software module is invoked by an application program that uses an out-of-date invocation syntax.
Not all software architectures exhibit this kind of problem. For example, some application programs are statically linked. In these more traditional software architectures, a linking program resolves all references made to external software modules residing in libraries. The linker then builds a self-contained, stand-alone executable program that contains a copy of every software module required by the program. Once a final executable program has been created by the linker, subsequent modifications to the external software libraries will have no effect. This is because the previously-created executable program still includes a copy of the older version of the required software modules.
Because static linking software architectures create stand-alone executable programs, every statically linked program that uses a software module obtained from a given software library will contain a separate copy of the module's executable code that has been extracted from that library. For this reason, after a program has been statically linked, if a component software module is then updated to correct errors, the statically linked program will not receive the benefit of that update. A technique known as “dynamic linking” addresses this concern by creating a dynamic link library. A dynamic link library (DLL) is a relocatable software library that is linked to a program at run time—that is, whenever the program is executed. Unlike statically linked programs, a program created in a dynamic linking environment does not contain a copy of every software module required by the program. Instead, when a dynamically linked program is loaded into memory, a linking loader first ascertains whether the required DLL is already resident in memory. If it is not, the DLL must be loaded by a linking loader into a free area of memory and its base address determined. All outstanding references to software modules within the DLL are then resolved by the linking loader, and execution of the program is allowed to proceed.
Dynamic linking ensures that only one copy of a library module will be loaded into memory when a program executes. All programs share the same version of the library. Thus, when a DLL is updated, all programs that subsequently invoke a software module in that DLL will automatically use the updated version.
Other known software architectures include features that are similar to dynamic linking. For example, a remote procedure call (RPC) provides an interface mechanism that permits a local program to invoke a software module that resides on a remote computer. The local calling program sends an RPC invocation message, including any required parameters, to a remote computer. A message receiver on the remote computer accepts the message, invokes the proper software module on behalf of the calling program, and then sends the results back to the calling program. As in the case of DLLs, if a remote software module is updated, the new version becomes immediately available to all calling programs that invoke it.
In object oriented architectures, a software library may maintain software objects that have been developed to perform critical or commonly-used functions. Such an object-oriented software library may reside locally on the same computer that executes a calling application program. On the other hand, an object-oriented software library may reside remotely on another computer. When an application or calling program sends a message to an object (thereby invoking a corresponding object method), an underlying software utility may access the library, locate the appropriate object, and invoke the object using a local dynamic invocation method or it may invoke the object using a remote invocation method, depending on where the object is located.
When dynamically linked or remotely invoked software modules or objects are modified by a software developer, a calling program that uses the modified software module or object may cease to function as designed, depending on the extent of the modification. If the underlying software architecture is one that includes runtime syntax checking, a program that functioned well previously may suddenly generate errors and stop executing if, for example, an updated software module is invoked with an old parameter list. On the other hand, if the changes are not significant enough to cause a runtime system to generate a syntax error, the calling program may nevertheless experience other runtime errors if the updated software module is invoked, for example, with a parameter that supplies a value that is no longer within an acceptable range or the parameter is supplied in an out-of-date format.
Similar errors may occur if a software architecture detects that a library has been updated relative to a calling application, and automatically attempts to recompile the application. In this situation, an application program that previously performed flawlessly may suddenly no longer execute because compilation errors materialized after an underlying software library was updated.
Accordingly, there is a need in the art for a system and method to monitor updates to software libraries and to notify appropriate software engineers when a modification is likely to cause a given software module to be no longer backward compatible with previous versions.